在《Go 网络编程和 TCP 抓包实操》Conn.Close() 方法发起了关闭 TCP 连接的请求，这是一种默认的关闭连接方式。

默认关闭需要四次挥手的确认过程，这是一种”商量“的方式，而 TCP 为我们提供了另外一种”强制“的关闭模式。

如何强制性关闭？具体在 Go 代码中应当怎样实现？这就是本文探讨的内容。

相信每个程序员都知道 TCP 断开连接的四次挥手过程，这是面试八股文中的股中股。我们在 Go 代码中调用默认的 Conn.Close() 方法，它就是典型的四次挥手。

以客户端主动关闭连接为例，当它调用 Close 函数后，就会向服务端发送 FIN 报文，如果服务器的本端 socket 接收缓存区里已经没有数据，那服务端的 read 将会得到一个 EOF 错误。

发起关闭方会经历 FIN_WAIT_1 -> FIN_WAIT_2 -> TIME_WAIT -> CLOSE 的状态变化，这些状态需要得到被关闭方的反馈而更新。

默认的关闭方式，不管是客户端还是服务端主动发起关闭，都要经过对方的应答，才能最终实现真正的关闭连接。那能不能在发起关闭时，不关心对方是否同意，就结束掉连接呢？

答案是肯定的。TCP 协议为我们提供了一个 RST 的标志位，当连接的一方认为该连接异常时，可以通过发送 RST 包并立即关闭该连接，而不用等待被关闭方的 ACK 确认。

在 Go 中，我们可以通过 net.TCPConn.SetLinger() 方法来实现。

而 sec == 0 时，操作系统会直接丢弃掉缓冲区里的流量数据，这就是强制性关闭。

我们通过示例代码来学习 SetLinger() 的使用，并以此来分析强制关闭的区别。

以服务端为主动关闭连接方示例

服务器和客户端建立连接之后，从客户端读取到数据 Hi, gopher? 。在 10s 后，服务端强制关闭了 TCP 连接，阻塞在 c.Read 的服务端代码返回了错误: use of closed network connection。

运行客户端代码

客户端和服务器建立连接之后，发送数据给服务端，服务端返回相同的数据 Hi, gopher? 回来。在 10s 后，由于服务器强制关闭了 TCP 连接，因此阻塞在 c.Read 的客户端代码捕获到了错误：connection reset by peer。

tcpdump 的抓包结果

我们重点关注内容 Flags []，其中 [S] 代表 SYN 包，用于建立连接；[P] 代表 PSH 包，表示有数据传输；[R]代表 RST 包，用于重置连接；[.] 代表对应的 ACK 包。例如 [S.] 代表 SYN-ACK。

搞懂了这几个 Flags 的含义，那我们就可以分析出本次服务端强制关闭的 TCP 通信全过程。

我们和《Go 网络编程和 TCP 抓包实操》

可以看到，当通过设定 SetLinger(0) 之后，主动关闭方调用 Close() 时，系统内核会直接发送 RST 包给被动关闭方。这个过程并不需要被动关闭方的回复，就已关闭了连接。主动关闭方也就没有了默认关闭模式下 FIN_WAIT_1 -> FIN_WAIT_2 -> TIME_WAIT -> CLOSE 的状态改变。

本文我们介绍了 TCP 默认关闭与强制关闭两种方式（其实还有种折中的方式：SetLinger(sec > 0)），它们都源于 TCP 的协议设计。

在大多数的场景中，我们都应该选择使用默认关闭方式，因为这样才能确保数据的完整性（不会丢失 socket 缓冲区里的数据）。

当使用默认方式关闭时，每个连接都会经历一系列的连接状态转变，让其在操作系统上停留一段时间。尤其是服务器要主动关闭连接时（大多数应用场景，都应该是由客户端主动发起关闭操作），这会消耗服务器的资源。

如果短时间内有大量的或者恶意的连接涌入，我们或许需要采用强制关闭方式。因为使用强制关闭，能立即关闭这些连接，释放资源，保证服务器的可用与性能。

当然，我们还可以选择折中的方式，容忍一段时间的缓存区数据处理时间，再进行关闭操作。